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Abstract : The launch site processing flow involves operations such as functional verification, preflight servicing and 
launch. These operations often include hazards that must be controlled to protect human life and critical space 
hardware assets. Existing command and control capabilities are limited to simple limit checking during automated 
monitoring. Contingency actions are highly dependent on human recognition, decision making, and execution. Many 
opportunities for Integrated System Health Engineering and Management (ISHEM) exist throughout the processing 
flow. This paper will present the current human-centered approach to health management as performed today for the 
shuttle and space station programs. In addition, it will address some of the more critical ISHEM needs, and provide 
recommendations for future implementation of ISHEM at the launch site. 


Introduction to Launch Site 
Operations 

Launch site operations begin with the 
arrival of flight hardware which can range 
from an individual component shipped from 
a vendor to a fully assembled vehicle that 
has returned from 
a recent space 
mission. Upon 
arrival, 

acceptance tests 
and inspections 
are performed to 
assess the 

hardware’s health. Hardware that arrives 
from a vendor is usually subjected to a 
complete end-to-end test of its electrical 
systems, including copper path (continuity) 
checks, stray voltage (isolation) checks and 
channelization (interface) tests. Hardware 
which is reusable and has proven system 
functionality during flight is generally not 
subjected to the same rigorous test protocols 
that are required for new hardware. Copper 
path testing is performed to verify signal 
continuity following connector de-mates. 
These de-mates are often the result of 
intrusive redundancy test procedures. 

Prior to flight, functional testing is 
performed to certify hardware capabilities 
such as system functionality and redundancy 
paths. Hardware capabilities are often tested 


in a non-integrated environment such as the 
Orbiter Processing Facility (OPF) which is 
used to test only an orbiter and not a fully 
assembled shuttle. These functional tests are 
frequently re-performed at the Launch Pad 
after the orbiter has been stacked with its 
Solid Rocket Boosters (SRB) and External 
Tank (ET) into an integrated shuttle system 
and moved into launch position. Some 
functional tests are performed each time 
power is applied regardless of where the 
orbiter is in its processing flow. 

Human Centered Health 
Engineering and Management 

In today’s launch site test environment, 
system health engineering and management 
is typically human-centered. Tests are 
performed by engineers who determine 
when non-conformances occur and initiate 
the proper paperwork to document the 
anomaly. In some cases, software is used 
to automate data collection or summarize 
results but it is ultimately the responsibility 
of the engineer to evaluate the data to 
determine if an anomalous condition exists. 

Today’s Human-Centered Health 
Engineering and Management (HCHEM) 
approach to launch site test and evaluation is 
costly, inefficient and dependent on the 
available engineering expertise. The goal of 
an ISHEM approach is to improve the 




ability to accurately detect anomalies in a 
more timely and consistent manner than 
HCHEM techniques can provide. 

The following sections will discuss current 
launch site health engineering and 
management problems and will suggest 
areas where replacing HCHEM with ISHEM 
will benefit launch site operations. 

Space Shuttle Turnaround 
Operations 

Most of the time required to turnaround 
space shuttle hardware is spent determining 
hardware condition following the previous 
flight 1 . The majority of this time is spent 
performing structural and thermal protection 
system inspections; and verifying the 
integrity of the various fluid systems. A 
significant amount of additional time is 
spent performing unplanned work associated 
with troubleshooting anomalies, replacing 
failed components (including removal of 
system components to gain access) and 
performing retest. Finally, system functional 
testing is performed to assess the hardware’s 
readiness to support the next phase of the 
processing flow. 

Inspections are typically labor-intensive 
operations where an experienced engineer 
uses techniques such as: dye penetrant 
inspections to detect the depth of dings and 
scratches; eddy current measurements to 
assess structural health; other non- 
destructive evaluation approaches which 
have become available throughout the years. 
These techniques provide the engineer with 
information that can be used to determine if 
an anomalous condition exists and rely on 
the engineer’s knowledge of system 
specifications and previous test results. In 
the case of dye penetrant inspections, 
acceptable dings and scratches are entered 
into a “Ding Log” which is used to 
document and track known conditions. 
These logs require manual entries that cite 


the position, shape and depth of the 
anomaly. 

Fluid systems are revalidated after every 
flight because all fluid systems leak. Many 
of the fluids, such as oxygen and hypergols, 
are corrosive and will damage system seals 
and components over time which will lead 
to leaks. Some leaks that are deemed 
acceptable following an inspection may 
become unacceptable at a later point in time. 
One area of particular concern is the ability 
to accurately characterize the current state of 
a fluid system. This characterization is 
impeded by two problems. The first problem 
is that many fluid system areas are not 
instrumented so the ability to directly sense 
the current state is not available and must be 
inferred. The second problem is that many 
shuttle sensors are not regularly calibrated 
and can therefore provide inaccurate 
information. To compensate, engineers 
maintain manual “cheat sheets” that adjust 
for error based on sensor readings that are 
obtained under known conditions; such as 
the value of ambient pressure a pressure 
sensor should read at sea level. The engineer 
must calculate the actual pressure value 
based on the returned sensor reading and the 
known error obtained from the “cheat 
sheet.” For example, a pressure sensor 
should read ambient pressure at sea level as 
14.7 psia; however some shuttle pressure 
sensors may read this value within a range 
of -2.0 to 45 psia. A pressure sensor whose 
“cheat sheet” value indicates that it reads 
ambient pressure as 5 psia is offset by 9.7 
psia. So when the sensor indicates that the 
system is at a pressure of 15 psia, the 
engineer must actually add the offset value 
to determine that the actual pressure is 24.7 
psia. This scenario occurred in 1995 in the 
orbiter’s Orbital Maneuvering System 
(OMS). A test engineer inadvertently failed 
to compare the value returned by a pressure 
sensor against the “cheat sheet” offset and 



believed that the OMS system was at 
ambient pressure. When a technician 
opened the joint instrumented by this sensor, 
fluid escaped and started a fire in the OPF 
around the 
orbiter 
Discovery." 

Unplanned 
work is the 
result of an 
HCHEM 

system that reacts to component failures as 
opposed to an ISHEM system that detects 
component degradation before failure limits 
have been exceeded. In other words, current 
launch site monitoring capability is designed 
to react based on pass/fail criteria as 
opposed to determining the component 
health and annunciating degraded 
conditions'". In the case of a valve with 
open and closed positions, indicators 
provide insight into when an open or closed 
command is sent to the valve and whether or 
not the valve responded properly. While 
these indications generally provide enough 
information to declare the valve either 
functional or non-functional, they provide 
little insight into its health. An experienced 
engineer may be able to infer some health 
information from the indicator readings; 
however, the scope of what can be inferred 
is limited by the type of information being 
sensed. 

For example, timing data is collected when 
Main Propulsion System (MPS) propellant 
valves are cycled open or closed. In this 
case, the propellant valve has two indicators, 
one located at the open position and the 
other at the closed position. When the valve 
is commanded open, the closed indicator 
will change state first. The open indicator 
will then change state once the valve has 
traveled to the fully open position. An 
experienced engineer uses this data to infer 


whether or not the valve has become 
sluggish when starting to move or slow to 
cycle from one position to another. This 
inferred health detection is accomplished by: 
comparing the time the command is sent to 
when the first indicator changes state 
(detects sluggish valve); and comparing the 
time the first indicator changes state to when 
the second indicator changes state (detects 
slow to cycle). 

System functional testing includes 
redundancy verification including: power, 
command paths and data paths. While 
avionics systems have more redundant paths 
than electro-mechanical systems, testing is 
generally more automated and therefore less 
time-consuming. 

Space Station Element 
Integrated Testing 

The Kennedy Space Station Payload 
Processing Directorate tests all of the 
payload items that will go into the Shuttle 
Bay. This includes the elements of the 
International Space Station (ISS), the Multi- 
Purpose Logistics Modules (MPLM), and 
experiments that will fly onboard the ISS or 
Shuttle. This testing is done in the Space 
Station Processing Facility (SSPF) and is the 
final functional testing performed before 
launch. 

ISS Test & Verification 

Multi-Element Integrated Testing (MEIT) is 
the testing of system functionality and 
interface compatibility between 
International Space Station elements. A 
standalone test is the testing of a single 
element to ensure functionality after 
shipment to KSC and prior to interfacing 
with the ISS. It can also satisfy 
requirements that haven’t been met through 
previous testing at a different site. A MEIT 
or Standalone takes several years to develop 
and execute. Agreements are made during 



Phase A (source gathering), such as 
concepts, testing ground rules, and 
responsibility test plan need to be made 
between International Partners, participants, 
and the ISS Program. Detailed Test 
Objectives (DTO) need to be developed 
evaluated and approved during Phase B 
(definition). This includes identifying 
support equipment and software, testing 
timeline, interdependent subsystems and 
their associated activities. Phase C (design) 
involves requirements development for 
functional testing, support equipment and 
software. For Space Station Processing 
requirements are known as ACOMC or 
OMRSD. During Phase D (development) 
test schedules are base-lined, integrated test 
procedures and test support products are 
developed, team members are identified and 
a console team is formed, test site 
preparations are completed, and off-site risk 
reduction activities are performed at ISIL. 
All pre-test (constraints review, readiness 
review, and pre-test briefing) and test 
activities are performed during Phase E 
(Operations). Phase F is the closure phase. 
The post-test debriefings are conducted, all 
paper is dispositioned and closed, and 
lessons learned are gathered. 

MEIT 1 included 3 A (Z1 Truss/Pressurized 
Module Adaptor #3), 4A (Integrated 
Electronics Assembly/P6 Long Spacer), 5A 
(US Lab), 5A.1 (Racks), 6A (Space Station 
Robotic Manipulator System), Flight 
Emulator (Node), and CITE (Cargo 
Integration Test Equipment). There were 
six configuration changes in MEIT1. MEIT 
2 included 8A (SO Truss/Mobile 
Transporter/Mobile Base System), 9A (SI 
Truss), 1 1 A (PI Truss), 12A (P3/P4 
Trusses), Flight Emulator (Node and US 
Lab). MEIT had five different 
configurations. MEIT 3 included 10A 
(Node 2), 1J (Japanese Experiment Module 
- Pressurized Module), and the Flight 


Emulator. Each of these includes regression 
testing for requirements that weren’t met 
due to time constraints or technical issues 
and needed to be re-tested. 

ISS Utilization/Research 

Payloads/experiments can be accommodated 
in Facility Racks, EXPRESS Rack/Pallet, 
Mid-decks, and as Attached Payloads which 
connects them to the United States 
International Standard Payload Rack 
Checkout Unit (USICU) in the SSPF 
Intermediate Bay. The USICU emulates 
ISS. The verification and acceptance testing 
that is performed is the final payload-to-ISS 
functional interface testing and EXPRESS 
experiment-to-EXPRESS Rack functional 
interface testing. The USICU connects to 
the Payload Test and Checkout System 
(PTCS) which emulates the ground systems. 
PTCS includes an Enhanced Huntsville 
Operations Support Center (HOSC) which 
acts like the MSFC Payload Operations 
Integration Center (POIC). 



ISS Re-supply and Return 

The purpose of Re-supply and Return 
missions is to transfer racks, cargo, and 
Orbital Replacement Units to and from the 
ISS in order to keep the ISS operational and 
to maintain a capability for the ISS to 
conduct scientific research. Typical materiel 
transferred to and from the ISS includes: 
Science Payloads/Experiments; Flight Crew 
Items (food, clothing, personal hygiene, 
etc.); Logistics Items (tools, replacement 
parts, ORU, etc.). All of the items are 
transferred in a Multi-Purpose Logistics 
Module (MPLM). 

MPLM Processing Flow: 



The Test Control Monitor System (TCMS) 
is utilized for all of the testing described 
above. TCMS consists of integrated 
networks of computers, software, data 
communications devices, displays, and 
controls required to control and monitor 
flight systems Ground Support Equipment 
(GSE) in direct support of International 
Space Station (ISS) ground operations at 
KSC. TCMS emulates MCC-H during local 
test operations and is a sub-set of S-band 
downlink telemetry. 

Launch Pad Operations 

Launch Pad operations involve performing 
activities that must be accomplished prior to 
Launch Countdown. These activities 
include: loading hazardous storable 

propellants, installing ordinance, performing 
unplanned maintenance activities and 
checkout of the integrated shuttle system. 
Prior to loading hazardous storable 
propellants ground personnel, suited in 
special protective gear, service ground 
support equipment and perform facility to 
vehicle connections. Loading can only occur 
after these preparations have been 
completed. During loading operations, 
automated ground software cycles valves as 
needed to maintain a strict pressure and 
temperature profile. Since the amount of 
propellant transferred to the orbiter’s tanks 
cannot be directly measured, ground 
software performs complex calculations 


using pressure, flow rate and time to 
determine the actual density and amount of 
propellant loaded. 

Final checkout of the integrated shuttle 
system includes performance of leak checks, 
hydraulic system conditioning. Inertial 
Measurement System calibrations, and 
payload end-to-end testing. Performing 
leak checks and isolating leaks to specific 
components is a 
particularly difficult 
task. The lack of 
sensing capability 
makes it difficult to 
directionally isolate 
the leak and 
determine its leak 
rate. 

Ordinance loading 
requires the shuttle 
to be powered down and the launch Pad to 
be cleared of non-essential personnel. 

Launch Countdown 

Launch countdown involves powering up 
systems, configuring them for liftoff and 
performing final verification that that they 
are ready to support the launch and the 
mission. 

One of the most hazardous launch tasks 
involves loading cryogenic hydrogen and 
oxygen into the external tank. Strict 
temperature control is maintained during 
cryogenic operations, and is particularly 
critical during oxygen loading. Excess heat 
buildup in the oxygen system can lead to 
bubble formation which will travel up the 
feed line on the outside of the ET. A “water 
hammer effect” will occur as the bubbles 
burst at the orbiter/ET interface where the 
plumbing makes a 90 turn. A “water 
hammer effect” can be of sufficient 





magnitude to cause the line to rupture with 
catastrophic consequences. 

The dynamic nature of cryogenic propellant 
loading requires continuous evaluation of 
system health to identify anomalous 
conditions. This evaluation is performed by 
comparing current data to data obtained 
during previous loading activities performed 
on the given shuttle. The harsh environment 
created by cryogenic activities usually 
causes multiple hardware failures during 
each propellant loading. These hardware 
failures must be identified, assessed, and 
remediated. The types of hardware failures 
most often observed are: leaks, loss of 
electrical continuity due to pin contraction, 
and sensor errors caused by 
impedance/resistance changes. 

Integrated System Health 
Engineering and 
Management 

Integrated System Health Engineering and 
Management will greatly improve safety, 
mission effectiveness and supportabiiity 
over current launch site HCHEM 
techniques. ISHEM will tackle the problem 
space with an integrated scope, instead of 
focusing on one problem domain area. It 
will also provide an engineering approach to 
determining system health and will 
incorporate specific requirements and design 
solution space to adequately cover the 
integrated scope. Finally, it will provide a 
management function that will do more than 
just annunciate problems; it will work with 
the system’s control authority to initiate 
remedial actions. Some specific areas that 
need to be addressed for future or derived 
launch systems are discussed below. 

Sensing 

Advances in sensing capability are needed to 
provide detection and isolation of defects 


such as cracks, weaknesses, and scratches in 
sealing surfaces. These advances must be 
accomplished without adding weight to the 
spacecraft or increasing power usage. 
Advances are needed in how failure 
mechanisms are directly sensed. For 
example, how do you sense the physics of a 
given failure as opposed to just monitoring 
the effect of the failure in the component? 
To illustrate this point, sensing technologies 
are needed that can detect when the 
tolerance between a valve piston and 
cylinder have changed or the spring constant 
has become degraded instead of just 
monitoring valve functions, such as open 
and close indications. 

The change in valve piston-to-cylinder 
tolerance and degraded spring constant will 
ultimately lead to valve failure; however, 
they are extremely difficult to detect using 
current sensing technology. 

Integrated Data Environment 

Adequate monitoring and health 
determination require both current and 
historical data. An integrated capability is 
needed to easily access real-time and 
historical data based on a given part number 
and serial number or based on a given event. 
The current approach indexes data based on 
its vehicle location. For example, a 
measurement id might be V51P0088C1. 
“V51” indicates that this id is a 
measurement that belongs to the orbiter 
Landing and Deceleration System. “P” is a 
pressure designator. “0088” is its Landing 
and Deceleration System measurement 
location and “Cl” is the data path the 
measurement takes to get to the ground. 
This measurement id is not easily correlated 
to a component after it is removed and 
placed in another location. This approach is 
not only inflexible it is incapable of 
correlating data with a specific component. 
In an integrated data environment, the 
measurement would include metadata that 



would provide access to relevant data for 
any given component regardless of where it 
is located. 

Configuration Data Automation 

An ISHEM Configuration Data Automation 
capability would integrate measurement 
data, metadata and logistical data. The 
ability to track pertinent component 
configuration data is required to automate 
health assessment and improve situational 
awareness. For example, configuration data 
can be used to automatically track 
component power-on time. If the 
component fails after a given number of 
power-on hours, then all components with 
the same part number and comparable 
power-on hours must be evaluated. This 
would also aid in the tracking of hardware 
designated as Limited Operating Life Items 
(LOLI). This analysis today requires 
manual integration of data derived from 
multiple resources. Some of these resources 
currently provide limited data collection 
tools. Another example for configuration 
management would be the Electronic 
Connect/Disconnect Log (ECDL). The 
ECDL is entered manually in a database 
after a connection is mated or de-mated. 
This database could be linked to a drawing 
of the vehicle and updated when there is a 
connection made. A final example is the 
contents in the Re-supply Stowage 

Platforms (RSP), Re-supply Stowage Racks 
(RSR), or drawers. Currently the drawings 
and procedures have to be updated manually 
and weight and center of gravity 

measurements recalculated anytime 
something is removed or added. These 
items could be linked and aid in 
configuration management. 

An ISHEM Configuration Data Automation 
capability is needed that will integrate all 
sources of configuration data with other 
relevant data sources. For example, 


integrating component configuration data 
with its historical data would improve the 
ability to make detailed and refined health 
assessments. 


Summary 

Many ISHEM opportunities exist for future 
or derived vehicles that will be processed 
and launched at the launch site. This paper 
has merely scratched the surface by 
providing some of the higher priority 
ISHEM needs. Additional information on 
launch site health management needs can be 
found in the following documents: the 
Advanced Spaceport Technology Working 
Group (ASTWG) baseline report lv and the 
Advanced Range Technology Working 
Group (ARTWG) report v . These reports 
were generated by national working groups 
composed of leaders in industry, academia, 
and government. 

Past health management focus has been 
concentrated on the vehicle side such as 
Integrated Vehicle Health Management, 
Integrated Intelligent Vehicle Health 
Management, etc. However many 
opportunities exist for ground and launch 
site health management. A truly Integrated 
System Health Engineering and 
Management system can only be developed 
and successfully implemented when both the 
ground and vehicle requirements are jointly 
considered during the design process. 
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